Systems and methods of multicast transport call session control for improving forward bandwidth utilization

ABSTRACT

Methods and systems of for multicast transport call session control for improving forward bandwidth utilization are disclosed. Forward channel bandwidth utilization is improved through pipelining and in-band token control of the multicast protocol when there exists a multiplicity of data objects for delivery from the server ( 202 ) to the clients ( 208 ).

This application claims priority to U.S. Provisional Application No.60/472,254, filed May 21, 2003, the entire contents of which are herebyincorporated by reference.

FIELD OF THE INVENTION

This invention relates generally to telecommunication networks such asInternet Protocol (IP) networks using multicast delivery ofnon-real-time-data, and, more particularly, systems and methods ofmulticast transport call session control using pipeline overlay onmulti-threaded processes and token control for improving forwardbandwidth utilization.

BACKGROUND OF THE INVENTION

Multicast data delivery using a one source to many destinationscommunications model is widely used for media distribution, includingmedia distribution by satellite. A push model for data delivery entailssending data from a source site to associated destination or clientsites based on a delivery schedule maintained at the source site. In apull model for data delivery, the delivery schedule is maintained at thedestination site or sites, meaning data is delivered to a destinationsite on command from the destination site. Pull models generally do notrestrict destination sites to issuing delivery commands synchronously,and thus, in a pull model, data delivery to individual destination sitesis independent as to when data is to be delivered. For this reason, thepull model causes scheduling complexities for the source site and isgenerally less efficient in terms of bandwidth used to deliver the data.

A many-to-many or one-to-many multicast push model for mediadistribution offers manageable delivery scheduling as well as improvedbandwidth efficiencies. Multicasting offers improved bandwidthefficiencies by using the bandwidth once for data delivery as opposed tousing the bandwidth several times for each intended receive destination.Generally, many-to-many IP multicasting entails a dialog between servercomputers and client computers over an IP network that connects theservers to the clients. A one-to-many IP multicasting model involves oneserver computer and many client computers. A set of rules controls theserver-client dialog and governs the sequence of communication eventsbetween the servers and clients. These rules are collectively referredto as a protocol, and in the case of IP multicasting, an IP multicastingprotocol. A call session is the server-client dialog.

Some applications of media distribution include news story delivery totelevision broadcast stations, syndicated program delivery to televisionstations, corporate updates to geographically diverse company sites, andeducational material to several learning sites. In each of the abovecases, a multicast model of any variety may be applied, that is to say,any combination of push model or pull model with many-to-many orone-to-many multicast delivery. Many content distribution networkseither own or lease bandwidth capacity that enables their distributionnetwork to operate. In either case, bandwidth is a precious commoditythat should be optimized for usage in order to minimize costs andmaximize content distribution service. An example is a satellite-basedIP network where satellite transmission is the medium by which contentis multicast to several receive locations on a scheduled basis. In thisexample, the bandwidth commodity is satellite transponder capacity.Although existing multicast systems provide improved bandwidth overprior systems, room for improvement remains.

Accordingly, there is a need for systems and methods of multicastdelivery of non-real-time-data that provide more efficient utilizationof forward bandwidth in order to minimize costs and maximize contentdistribution.

SUMMARY OF THE INVENTION

Certain exemplary embodiments according to the present invention providesystems and methods for multicast transport call session control forimproving forward bandwidth utilization. According to certain exemplaryembodiments of this invention, forward channel bandwidth utilization isimproved through pipelining and in-band token control of the IPmulticast protocol when there exists a multiplicity of data objects fordelivery from the server to the clients. Certain exemplary embodimentsof this invention provide improved pipeline architecture for an IPmulticast protocol, passing tokens in order to control sending datathrough a forward channel in accordance with the architecture of thepipeline, and improved forward channel bandwidth utilization andefficiency.

An exemplary environment for operation of certain exemplary embodimentsof this invention is a one-to-many multicast IP network environment. Forinstance, the one-to-many multicast IP network may be a hybrid IPmulticast network where the forward channel is a satellite link betweenthe server and clients and the back channel from the clients to theserver is terrestrial.

According to certain exemplary embodiments of the present invention,each call session in a pipeline operates as a separate virtual orlogical channel within the physical forward channel. A pipeline isconstructed using a central control from which multiple child processesmay be initiated. Each child process constitutes one IP multicast callsession. Based on the depth of the pipeline constructed, a group of IPmulticast call sessions form a pipeline according to their predefined IPmulticast call session process steps. The central control is responsiblefor creating and controlling the pipeline, determining when an IPmulticast call session or sessions may send data through the forwardchannel. In an exemplary embodiment, a token or group of tokensmaintains at least partial control of the pipeline. One or more IPmulticast call sessions use a token or tokens to send data through theforward channel. If multiple tokens are used, then multiple IP multicastcall sessions are allowed to send data through the forward channelsimultaneously.

In one embodiment, a method for multicast delivery of a plurality ofcall sessions, each call session comprising at least one send dataprocess step and at least one wait process step, includes (a) providinga send token that controls which of the plurality of call sessions sendsdata through the forward channel; (b) moving the send token to a firstcall session at a send data process step; (c) upon reaching a waitprocess step of the first call session, moving the send token to asecond call session at a send data process step; (d) upon reaching await process step of the second call session or any subsequent waitprocess step of any of the plurality of call sessions, moving the sendtoken to an active call session that is at a second or subsequent senddata process step or, if no active call sessions are at a send dataprocess step, moving the send token to an uninitiated call session ofthe plurality of call sessions; and (e) repeating (d) until delivery ofeach of the plurality of call sessions is complete. Thetelecommunications network may be a one-to-many internet protocolnetwork with a satellite forward channel and a terrestrial back channel.Step (d) may include moving the send token to an active call session ata second or subsequent send data process step based on a priorityscheme. The priority scheme may be that the earliest initiated callsession receives the send token when the send token becomes available.Step (d) may include moving the send token to an uninitiated callsession according to an order in a queue of uninitiated call sessions.In another embodiment, a method of multicast delivery may includeproviding a second send token such that two call sessions may send datasimultaneously through a forward channel of the network.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an exemplary network topology for a one-to-many multicastnetwork environment.

FIG. 2 shows an exemplary network topology for a one-to-many hybrid IPmulticast network environment.

FIG. 3 shows a logical layer embodiment of the hybrid multicast networkenvironment of FIG. 2.

FIG. 4 illustrates an exemplary embodiment of process flow for mappingcall sessions to logical channels based on digital video broadcaststandard packet identifiers.

FIG. 5 shows an exemplary embodiment of process flow for an exemplarymulticast call session.

FIG. 6 shows an exemplary embodiment of parent-controlled processes forcontrolling a pipeline.

FIG. 7 illustrates relative sizes of exemplary multicast delivery jobsdepicted in FIGS. 8A-9F.

FIGS. 8A-8G show an exemplary embodiment of multicast delivery ofmultiple call sessions using a token-controlled pipeline according tothe present invention.

FIGS. 9A-9F show multicast delivery of multiple call sessions usingexisting systems and methods of serial delivery.

DETAILED DESCRIPTION OF THE INVENTION

Certain exemplary embodiments according to the present invention providesystems and methods for multicast transport call session control forimproving forward bandwidth utilization. These exemplary embodiments aremerely preferred embodiments of the invention; other embodiments of theinvention may be implemented by persons skilled in the art. According tocertain exemplary embodiments of this invention, forward channelbandwidth utilization is improved through pipelining and in-band tokencontrol of the IP multicast protocol when there exists a multiplicity ofdata objects for delivery from the server to the clients.

FIG. 1 shows an exemplary embodiment of a one-to-many multicast IPnetwork environment. The environment shown in FIG. 1 is a multicastingpush model, but it should be understood that systems and methods of thepresent invention may be used with pull models as well as many-to-manymulticast networks. According to push models, a multicast server 102schedules and distributes content to several multicast clients 106 overan IP multicast network 104. IP multicast network 104 may be terrestrialbased, satellite based, optical, terrestrial wireless, or any other typeof IP multicast network well known to those skilled in the art. Anexample of a typical IP multicast network is shown in FIG. 2.

FIG. 2 shows an exemplary embodiment of a one-to-many multicast networkenvironment with a hybrid IP multicast network. As shown in FIG. 2, theforward channel is a satellite link between the server and clients, andthe back channel from the clients to the server is terrestrial. Themulticast network in FIG. 2 is referred to as a “hybrid” network becauseit includes a forward channel and a back channel that deliver data viadifferent means (e.g., a wireless forward channel and a wireline backchannel). The server, via an IP multicast server computer 202, an IPgateway 212, and a satellite dish 214, communicates with a satellite216, that in turn communicates with numerous clients, each with asatellite dish and IP receiver 208 and an IP multicast client computer206. This is the forward channel. IP multicast client computers 206communicate with IP multicast server computer 212 via Internet 210. Thisis the back channel.

As previously noted herein, content distribution via IP multicasting mayrequire distribution scheduling by the multicast server or servers fordelivering content data objects over the network to destination clients.Often, content distribution involves a plurality of diverse content dataobjects that require distribution to designated clients over a specifiedtime period. In such situations, the forward channel bandwidth may beoptimized for high usage based on scheduling and the methodologyemployed by an IP multicasting protocol. For example, if a batch of dataobjects are scheduled for delivery, one technique is serial delivery,which entails sending one job at a time and including a waiting periodbetween each data object delivery session. Waiting periods arise as anatural consequence of the multicasting call session protocol chosenbecause there exist portions of a multicast call session where no datais being sent through the forward channel. The measured forward channelutilization is far less than 100% using this serial delivery technique.

Modem operating systems for servers and client computers permit multiplecomputing processes to coexist. Operating systems that have thiscapability are known as multi-tasking operating systems. Computerprograms that exploit multi-tasking operating systems do so by utilizingmultiple program threads that operate on different tasks simultaneously.Certain exemplary embodiments of this invention utilize multi-threadingby overlaying a pipeline structure for the processing steps executedduring a call session for an IP multicast protocol. Pipelining permitsservicing several data objects for multicast delivery as each deliverycall session is in a different stage of its respective multicastdelivery. Multiple multicast call sessions are processed and coordinatedby using an in-band control scheme that preserves the pipeline structureand ensures improved forward channel bandwidth utilization compared toserialized management of different call sessions.

According to certain exemplary preferred embodiments of the presentinvention, each call session in the pipeline operates as a separatevirtual or logical channel within the physical forward channel. It iscommon to refer to a physical channel based on physical characteristics,such as transmission frequency, transmission bandwidth, and in the caseof satellite communications, spatial orbit. A virtual or logical channelis generally defined by an addressable parameter, such as IP address orpacket identifier (PID) addresses.

Most digitally-based satellite communications systems use standardpacket based transport concepts defined by the digital video broadcast(DVB) standard. The DVB standard for satellite communications permitslogical channel assignments based on PID values assigned to packets ofdata. For example, either DVB or some other logical channel assignmentstandard would be used in the exemplary environment shown in FIG. 2.FIG. 2 shows an IP gateway that receives IP packets from a multicastserver. The IP gateway encapsulates the received packets into anotheraddressable packet scheme such as DVB. The concept of logical channelspermits segmenting of a physical channel into several logical channelsthrough time division multiple access (TDMA) methods, which are wellknown to those skilled in the art. For more information regarding IPpacket addressing, the reader is referred to “RFC791,” and forinformation on DVB packet addressing and DVB encapsulation, the readeris referred to “ISO/IEC 13818-1 Generic coding of moving pictures andassociated audio information: Systems” and “ISO/IEC 13818-6 Genericcoding of moving pictures and associated audio information—Part 6:Extensions for DSM-CC,” respectively, each of these documents being wellknown to those skilled in the art and incorporated herein by referencein their entirety.

FIG. 3 shows a logical layer embodiment of the hybrid multicast networkenvironment of FIG. 2. FIG. 4 illustrates an exemplary embodiment ofprocess flow for mapping call sessions to logical channels using DVBstandard PIDs. As shown in FIG. 4, there is a multiplicity of callsessions or delivery jobs (N jobs) accessible from a database.Initially, delivery jobs are fetched until the depth of the call sessionpipeline has reached capacity, M jobs in this example. Once the callsession pipeline is full, the, next delivery job is fetched upontermination of an active call session, placing a new delivery job in thevacated pipeline position. With proper coordination among delivery jobsin the call session pipeline, improved forward channel bandwidthutilization is achievable.

A call session in an IP multicast protocol generally includes a set ofprocess steps. Generally, a call session includes three fundamentaloperations: (1) call setup, (2) call data send (i.e., sending thedelivery job data through the forward channel); and (3) calltermination. In some instances, an IP multicast delivery network handlesmission critical jobs where a back channel is used so that deliverysites may notify the multicast server when a portion of the delivery jobwas not received. When notification arrives, the multicast serverresends missed portions of the delivery job to all receive clients thatindicated a portion was not received through their respective backchannels. Therefore, sending a delivery job through the forward channelmay entail several iterations in order to ensure reliable job delivery.The environments shown in FIGS. 2 and 3 incorporate a back channel fornotification of missing portions of a delivery job and/or confirmationof delivery success. An Internet back channel is shown in each figure,but any other suitable back channel means may be used, as is wellunderstood by those skilled in the art. For example, a satellite backchannel based on very small aperture terminal (VSAT) technology may beused.

FIG. 5 shows an exemplary embodiment of process flow for an exemplary IPmulticast call session from the perspective of a multicast server. Asnoted herein, there are three broad categories for these process steps:process steps that send data through the forward channel; process stepsthat perform non-sending or non-receiving operations of a call session;and process steps that receive data from the back channel. A morerefined and detailed example of an IP multicast call session operationalprotocol, including eight process steps, is shown in FIG. 5 anddescribed further below. It should be noted that process steps P3-P8show the actual call session dialog between the multicast server and themulticast clients.

State transition rules for the exemplary IP multicast call session shownin FIG. 5 are as follows: (a) each process step or state may havemultiple entry points and multiple exit points; (b) if a process step orstate has multiple input arrows to the same entry point, it is anindication that the process step or state may start only after all inputarrows convey a true condition; (c) if a process step or state has aninput arrow or arrows to two or more entry points, then that processstep or state is started upon the first occurrence of either entry pointconveying a true condition considering all inputs to that entry point;and (d) if a process step or state has more than one exit point, thenthat process step state may exit based on different exit conditions.

The process steps outlined in the exemplary embodiment shown in FIG. 5provide a particular example of an IP multicast transport protocol. Itshould be understood that systems and methods of the present inventionare not limited to the exemplary eight-step IP multicast call sessionprotocol described herein and that the present invention allows numerousembodiments of an IP multicast call session protocol to operate in apipeline fashion with multi-threaded control rules such that forwardchannel utilization is optimized when there exists a multitude ofdistribution jobs. Other aspects according to systems and methods of thepresent invention, such as pipeline architecture, are shown in FIGS. 6and 8A-8G and described in detail below. FIG. 5 does not include anypipeline or associated control and illustrates an event driven processtransition diagram (i.e., process transitions are based on eventoutcomes).

Referring now to FIG. 5, each of the eight exemplary process steps, P1through P8, are as follows:

P1: Fetch Call Session Job.

The call session job is fetched from the job queue. Generally, but notalways, multicast delivery jobs are held in an accessible storagemedium, such as a standard database.

P2: Send Open Call Session Message.

An open call session message is sent to the designated receive clients.This message officially opens a call session to a designated pool ofclients. The client list is typically unique for each multicast job, butthe client list may be fixed for all multicast jobs.

P3: Collect Open Call Session Responses.

Responses to the open call session message are collected from designatedclients. Because clients are normally physically remote, it is necessaryto assess which clients within the client pool are ready for a callsession. If all the designated clients respond, normal operations mayproceed. However, if less than the total number of designated clientsrespond, some other appropriate action may be taken, such as continuingwith the call session or terminating the call session immediately. Inthe call sessions shown and described in FIGS. 8A-9F, it is assumed thatall of the designated clients respond and normal operations proceed.This step is a waiting process (i.e., no data is being sent). If noother process is sending data during this time; then the forwardbandwidth is not used during this wait period. In the call sessionsshown and described in FIGS. 8A-9F, it is assumed that this waitingperiod is a known, fixed time period for all multicast jobs distributed.

P4: Send Call Session Job Data and Reset Resend Count to Zero.

The size of each delivery job is time-varying. A resend counter in thisparticular IP multicast call session protocol facilitates resendingmissing job data multiple times. The resend counter is not required butit is prudent to allow for resending missing job data in cases wheredelivery jobs are mission critical. The resend count controls how manytimes the multicast server will attempt to send a job to the multicastclient pool before terminating the call session so that other deliveryjobs can be serviced.

P5: Send Call Session Response Request and Increment the Resend Count.

This message obtains feedback from the designated client pool on missedjob data. Positive acknowledgement messages or negative acknowledgementmessages convey this information. Other suitable acknowledgement messagesystems, which are well known to those skilled in the art, may be used.This process step increments the resend counter and is the first step ina loop (P5 through P7) that assesses multicast client reception todetermine if sending missing job data is required.

P6: Collect-Call-Session-Responses from Designated Clients and CheckMulticast Clients Reception Status.

This process step analyzes the reception status of the multicast clientpool. If missing job data needs to be sent, the protocol moves to P7. Ifall clients have received the job data, the protocol moves to step P8.This step is a waiting process (i.e., no data is being sent, similar toP3). In the call sessions shown and described in FIGS. 8A-9F, it isassumed that this waiting period is a known, fixed time period for allmulticast jobs distributed. P6 is the second step in a loop (includingP5-P7) that assesses the multicast client pool reception status todetermine whether to resend missing job data or terminate the callsession.

P7: Resend-Missing-Call-Session-Job-Data and Check if the Resend Counthas Reached its Maximum Allowed Value.

This process step has two exit points. For either exit point, missingjob data is sent to the multicast client pool. The exit points aredetermined based on the status of the resend count. If the resend counthas reached its maximum allowed value (N), then missing job data is sentand the process moves to P8. If the resend count is less than itsmaximum allowed value, then missing job data is sent and the processcontinues with P5. In an instance where job delivery to all designatedclients is mission critical, there may be several cycles of sending arequest for job acknowledgement, collecting responses, and resendingmissing call session data; generally referred to as a Data Resend Cycle.Due to the heterogeneous nature of the client pool, the number of timesa Data Resend Cycle is necessary to achieve complete delivery of jobdata to all designated clients is unknown and random. Therefore, most IPmulticast delivery systems fix the number of Data Resend Cycles based onachieving delivery to a majority of the designated clients. This valueis the maximum allowed value for the resend count, N. Typically, an IPmulticast delivery system reschedules clients for a later multicast whenthey do not reliably receive all the job data after exhausting all DataResend Cycles. A Data Resend Cycle generally includes execution of thefollowing process steps: P5, P6, and P7.

P8: Send Close Call Session Message.

This message officially terminates a call session.

A pipeline is constructed using a central control from which multiplechild processes may be initiated, as shown in FIG. 6. Each child processconstitutes one IP multicast call session. Based on the depth of thepipeline constructed, a group of IP multicast call sessions form apipeline according to their predefined IP multicast call session processsteps. The central control is responsible for creating and controllingthe pipeline, determining when an IP multicast call session or sessionsmay send data through the forward channel.

In an exemplary embodiment, a token or group of tokens maintains atleast partial control of the pipeline. Tokens are used by one or more IPmulticast call sessions to send data through the forward channel. Ifmultiple tokens are used, then multiple IP multicast call sessions areallowed to send data through the forward channel simultaneously. Forsimplicity, the exemplary preferred embodiment described herein withreference to FIGS. 8A-8G utilizes a single token. In the exemplaryembodiment, each IP multicast call session exists as a logical channelmapped within the physical instance of the forward channel and employingTDMA methods. Logical channel mapping within the physical forwardchannel is described herein and shown in FIG. 4.

In an exemplary embodiment, central control manages pipeline flow basedon the following rules:

(A) To ensure that the bandwidth is used during any process step thatdoes not send data through the forward channel, pipeline depth ismaintained such that another call session is at a pending send dataprocess step. This may require a large number of pre-fetched callsession jobs. Accordingly, unused bandwidth gaps may occur if the numberof jobs available during a call session pre-fetch is less than theparticular number of jobs necessary to maintain an ideal pipeline depth.

(B) To ensure that the pipeline maintains a flow of active call sessionjobs, call sessions jobs are pre-fetched whenever the predeterminedpipeline depth has an open position. An open position in the pipelinedepth is an indication that at least one call session job has terminatedor completed.

(C) Each send process or state in a call session should possess theSEND-TOKEN in order to send data. After completing a data send, a callsession relinquishes the SEND-TOKEN if its next process or statetransition is a non-sending process or state. When several call sessionsare vying for the SEND-TOKEN, a priority scheme may be employed. Forexample, call session age (i.e., the oldest call session gets priorityover younger call sessions), call session priority (i.e., higherpriority call sessions take precedence over lower priority callsessions), assigned quality-of-service (QoS) level priority (wherecertain call sessions are assigned a higher level QoS compared toothers), any combination of the above, or any other suitable scheme wellknown to those skilled in the art. Implementing a priority scheme forcontrolling the SEND-TOKEN ensures that the SEND-TOKEN is available whenthe highest priority call session is able to send its associated data.

FIGS. 8A-8G show an exemplary preferred embodiment of multicast deliveryof multiple call sessions using a token-controlled pipeline according tothe present invention. In this embodiment, there are seven multicastcall sessions, and for each, there are eight process steps, P1 throughP8, as shown in FIG. 5 and described herein. As shown in FIGS. 8A-8G, acall session process step is identified by a set of two numbers, thefirst number indicating the process step (1 through 8 corresponding tothe exemplary process steps P1 through P8 described herein) and thesecond number indicating the multicast call session (1 through 7). Forexample, the fourth process step of the second multicast call session isindicated by the set 4,2, the third step of the fifth call session isindicated by the set 3,5, and so on. In the exemplary embodiment shownin FIGS. 8A-8G, the number of Data-Resend-Cycles (i.e., P5-P7) islimited to three per call session and call session wait process steps P3and P6 are equally fixed time lengths for all seven call sessions.

The shaded areas along the forward channel bandwidth timeline illustratewhere bandwidth is unused, while the unshaded areas indicate wherebandwidth is used. The horizontal lines (within each call session)ending in arrows indicate that a call session is in a pending processstep that is ready to send data through the forward channel when theSEND-TOKEN becomes available. Diagonal lines (across call sessions) withan arrow in the middle and terminated with filled circles on both endsindicate how the SEND-TOKEN flows from one call session to another, withthe arrow indicating the direction which SEND-TOKEN flows. In theexemplary embodiment shown in FIGS. 8A-8G, there is only one SEND-TOKEN,but the systems and methods according to this invention may use aplurality of send tokens. Using one SEND-TOKEN reduces the complexity ofthe system, while using more than one SEND-TOKEN allows more than onecall session to send data through the forward channel bandwidth. Thebandwidth timeline is segmented across each FIG. 8A-8G with each segmentrepresenting a time continuum to demonstrate where in time the forwardchannel bandwidth is used by a multicast call session according to thisinvention.

The pipeline depth of the embodiment shown in FIGS. 8A-8G is seven andis selected based on the exemplary rules discussed above and anarbitrary rule of not allowing the number of simultaneous call sessionsto exceed seven. A random operation flow for each call session depictedin FIGS. 8A-8G is chosen to demonstrate how the pipeline and tokencontrol mechanism of this invention operate under various conditions.Table 1 shows the operation flow for each delivery job as depicted inFIG. 8A-8G. TABLE 1 Example Operation Flow for Multicast Call SessionsMulticast Call Session Number Multicast Operation Flow 1 ThreeData-Resend-Cycles performed thus reaching the maximum allowed and henceterminating after sending the third resend data. Each succeeding resenddata size is smaller then the previous. 2 One Data-Resend-Cycle withdecreasing resend data size. 3 No Data-Resend-Cycle necessary as allclients received the delivery job after the initial send data step,process step P4. 4 Two Data-Resend-Cycles with decreasing resend datasize. 5 Three Data-Resend-Cycles performed thus reaching the maximumallowed and hence terminating after sending the third resend data. Eachsucceeding resend data size is smaller then the previous. 6 ThreeData-Resend-Cycles performed thus reaching the maximum allowed and henceterminating after sending the third resend data. Each succeeding resenddata size is smaller then the previous. 7 Three Data-Resend-Cyclesperformed thus reaching the maximum allowed and hence terminating aftersending the third resend data. Each succeeding resend data size issmaller then the previous.

The seven delivery jobs shown in FIGS. 8A-8G vary in size based on theamount of time required to send job data through the forward channelbandwidth. The size of the forward channel bandwidth size is notsignificant, but, for the exemplary embodiment shown in FIGS. 8A-8G, theassigned forward channel bandwidth size is fixed. Variable multicastdelivery job sizes are shown in the embodiment of FIGS. 8A-8G. FIG. 7illustrates the relative size of the data to be delivered in step P4 ofeach call session, as well as step P7 for any Data-Resend-Cycles of acall session, in mega bits (Mb).

In the exemplary embodiment, the forward channel is assigned a fixedbandwidth of 10 Mbps (mega bits per second). The time required to send ajob through the forward channel is determined by the size of the jobdivided by the bandwidth. This relative measurement is used throughoutFIGS. 8A-8G (as well as FIGS. 9A-9F). Associating elapsed time with bitsis applicable to any data sent through a forward channel with a fixedbandwidth capacity, and this measurement is also used to relate therelative size of other process steps, such as P2, P5, and P8, in theexemplary eight-step multicast call session discussed herein.

As shown in FIGS. 8A-8G, when any call session is in either a P3 or P6state there is another call session ready to send data through theforward channel. There are periods where the forward channel bandwidthis not used as the pipeline is initially filling to its predefined depthand when the pipeline is emptying, which is common behavior for systemsemploying pipeline architecture. Pipeline architectures achieve maximumefficiency once the pipeline is filled and maintain these efficiencygains as long as the pipeline remains full.

In order to compare the forward channel bandwidth utilization andefficiency gains achieved in the exemplary embodiment of the inventionshown in FIGS. 8A-8G, another multicast delivery of multiple callsessions is shown in FIGS. 9A-9F. The operational parameters for themulticast delivery shown in FIGS. 9A-9F are the same as those for theembodiment of the invention shown in FIGS. 8A-8G except that themulticast delivery uses serialized process flow instead of atoken-controlled pipeline process. As can be seen in FIGS. 9A-9F, theforward channel bandwidth utilization is much lower than that in theexemplary embodiment of the invention shown in FIGS. 8A-8G.Additionally, for the same number of multicast delivery jobs and callsession operation flow, as shown in FIG. 7 and Table 1, the timerequired to complete delivery of all seven call sessions is longer whenusing the serialized process flow of FIGS. 9A-9F: 647 seconds (FIGS.9A-9F) compared to 395 seconds (FIGS. 8A-8G).

In the exemplary embodiment shown in FIGS. 8A-8G, all session data andcontrol is contained in the same channel, allowing channel assignmentresources to be maximized when compared with out of channel controlmethods that reduce the number of available channels for call sessiondata by at least one because at least one channel is used for sendingcontrol messages. Alternative methods and systems for improving forwardchannel bandwidth utilization apply out-of-band control rather than thein-band control shown in FIGS. 8A-8G. In such alternative methods andsystems, call session protocol is segmented into process steps that setup a call session and process steps that include actual call sessiondialog between a multicast server and clients. An embodiment of thisinvention employing out-of-band control includes dedicating a first setof forward channel packet addresses for call session set up messagingonly and a second set of forward channel packet addresses for thepipelined multicast call session dialog. For example, using theexemplary call session process steps shown in FIG. 5, out-of-bandcontrol may be implemented as follows: (1) map process steps P2, P5, andP8 to a dedicated DVB PID value (address); and (2) map process steps P4and P7 to a DVB PID value from a pool of available DVB PID values thatare used for simultaneous call sessions that are pipelined. Without-of-band control, clients must keep track of which control messagesreceived via the assigned DVB PID belong to which active call session inthe pipeline. This added complexity does not exist in in-band controlbecause call data received by clients over a particular DVB PID belongsto only one call session.

The foregoing description of the exemplary embodiments of the inventionhas been presented only for the purposes of illustration and descriptionand is not intended to be exhaustive or to limit the invention to theprecise forms disclosed. Many modifications and variations are possiblein light of the above teaching. The embodiments were chosen anddescribed in order to explain the principles of the invention and theirpractical application so as to enable others skilled in the art toutilize the invention and various embodiments and with variousmodifications as are suited to the particular use contemplated.Alternative embodiments will become apparent to those skilled in the artto which the present invention pertains without departing from itsspirit and scope.

1. A method for multicast delivery of a plurality of call sessions, eachcall session comprising at least one send data process step and at leastone wait process step, the method comprising: (a) providing a send tokenthat controls which of the plurality of call sessions sends data throughthe forward channel; (b) moving the send token to a first call sessionat a send data process step; (c) upon reaching a wait process step ofthe first call session, moving the send token to a second call sessionat a send data process step; (d) upon reaching a wait process step ofthe second call session or any subsequent wait process step of any ofthe plurality of call sessions, moving the send token to an active callsession that is at a second or subsequent send data process step or, ifno active call sessions are at a send data process step, moving the sendtoken to an uninitiated call session of the plurality of call sessions;and (e) repeating (d) until delivery of each of the plurality of callsessions is complete.
 2. The method of claim 1, where thetelecommunications network is a one-to-many internet protocol networkwith a satellite forward channel and a terrestrial back channel.
 3. Themethod of claim 1, wherein (d) further comprises moving the send tokento an active call session at a second or subsequent send data processstep based on a priority scheme.
 4. The method of claim 3, wherein thepriority scheme is that the earliest initiated call session receives thesend token when the send token becomes available.
 5. The method of claim1, wherein (d) further comprises moving the send token to an uninitiatedcall session according to an order in a queue of uninitiated callsessions.
 6. The method according to claim 1, farther comprisingproviding a second send token such that two call sessions may send datasimultaneously through a forward channel of the network.